(19) 



EuropSlsches Patentamt 
European Patent Office 
Office euro pee n des brevets 



(12) 



(ID EP 1 255 416 A1 
EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

06.11.2002 Bulletin 2002/45 

(21) Application number: 01110877.6 

(22) Date of filing: 04.05.2001 



(51) mtci7: H04Q 7/32, H04M 3/533, 
H04L 12/58 



(84) Designated Contracting States: 


(72) 


Inventors: 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


• 


La u men, Josef 


MCNLPT SETR 




31141 Hildesheim (DE) 


Designated Extension States: 


• 


Schmidt, Andreas 


AL LT LV MK RO SI 




38114 Braunschweig (DE) 




• 


Trauberg, Markus, Dr. 


(71) Applicant: SIEMENS AKTIENGESELLSCHAFT 




38159 Vechelde (DE) 


80333 Munchen (DE) 


• 


Van Niekerk, Sabine 






38228 Salzgitter (DE) 



(54) Method and medium for storing and accessing MMS (Multimedia Messaging Service) 
information 



(57) Method for storing MMS (Multimedia Messag- 
ing Service)-related information, related method for ac- 
cessing MMS-related information, related storage me- 
dium, related apparatus and related software programs 
The invention relates to method for storing MMS 
(Multimedia Messaging Service)-related information, 
wherein said information is stored on at least one stor- 
age medium connected to a mobile communication ap- 



paratus which supports MMS services or a device con- 
nected to such a mobile communication apparatus, said 
at least one storage medium being disconnectable from 
said apparatus or said device. Furthermore, the inven- 
tion concerns a related method for accessing MMS-re- 
lated information by an apparatus adapted to process 
said MMS-related information, a related storage medi- 
um, a related apparatus and related software programs. 
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Description 

[0001] Method for storing MMS (Multimedia Messaging Service)-retated information, related method for accessing 
M MS- related information, related storage medium, related apparatus and related software programs 
5 [0002] The invention relates to a method for storing MMS (Multimedia Messaging Service)-related information. 

[0003] Furthermore, the invention concerns a related method for accessing MMS-retated information by an apparatus 
adapted to process said MMS- related information, a related storage medium, a related apparatus and related software 
programs. 

[0004] Currently a new messaging service, the so called MMS (Multimedia Messaging Service) is being standardized. 
io Contrary to SMS (Short Message Service) MMS messages can contain multimedia elements like for example text, 
image, audio or video. E.g. MMS is planned to be installed in mobile communication systems of the 3 rd generation 
such as UMTS (Universal Mobile Telecommunication Service). 

[0005] MMS as shown in Figure 1 is a known peer-to-peer messaging service between two MMS User Agents (UA_A, 
UA_B) which are each connected to an MMS Relay/Server (RS_1 , RS_2) each comprising an MMS Relay (R) and an 

15 MMS Server (S) both being connected via an interface called MM2. Both MMS Relay/Server (RS_1 , RS_2) are con- 
nected via an interface called MM4. Furthermore, each MMS Relay/Server (RS_1 , RS_2) can be connected to one or 
more external servers (ES_1 , ES_N) via interfaces called MM3 as well as MMS User Databases (UD) via an interface 
called MM6 and a Home Location Register via an interface called MM5. The User Agents (UA_A, UA_B) reside on a 
mobile phone, e.g. a UMTS-UA (User Equipment) or a GSM-MS (Mobile Station), or on an external device, e.g. a 

20 notebook/laptop, connected to a mobile phone. It is an application layer function that provides the user with the ability 
to view, compose and handle the Multimedia Messages (MMs), e.g. submitting, receiving, delivering of MMs. The MMS 
Relay/Server is a network entity responsible for storage and handling of incoming and outgoing messages and for the 
transfer of the message between different messaging systems. 

[0006] MMS has several MMS-related information which is necessary for using MMS as messaging service. Impor- 
ts tant MMS-related information are for example: the MMS notification, the MMS delivery report, the MMS read reply 
report, MMS service parameters, the Multimedia Message itself, etc. 

[0007] A user's MMS-related information is only available on a single terminal/device. If a user changes his terminal 
all MMS-related information is lost. If e.g. a user changes his terminal before downloading an MM he has been notified 
of this new MM is lost. He can not download it from a terminal different from the one he used when he was notified. 

30 [0008] It is the goal of the present invention to allow users to handle MMS services with more flexibility. 

[0009] Concerning the above mentioned method for storing MMS-related information this goal is accomplished via 
the features of independent claim 1 . Concerning the above mentioned method for accessing MMS-related information 
this goal is accomplished via the features of independent claim 2. Concerning the related storage medium this goal is 
accomplished via the features of independent claim 24. Concerning the related apparatus this goal is accomplished 

35 via the features of independent claim 34. Concerning the related software programs this goal is accomplished via the 
features of independent claims 37 and 38, respectively. 

[0010] The present invention proposes to store MMS-related information or parts of MMS-related information on 
media different from the user's terminal, especially 

40 - Storage on a SIM (Subscriber Identity Module) or a USIM (UMTS Subscriber Identity Module) on the UICC (Uni- 
versal Integrated Circuit Card). 

Storage on a WIM (Wireless application protocol Identity Module) on the UICC. 

Storage on a smart card which is not one of the above, especially an MMC (Multimedia Card). 

45 it is also proposed to allow a user to have a combination of these storage possibilities. Such a combination can be a 
SIM and a USIM, or a USIM and a MMC, for example. Likewise, more than two storage mediums can form such a 
combination. 

[0011] Furthermore, this invention identifies 

so - the information that is useful to be stored on such a repository, and 

proposes mechanisms how to achieve the storage of MMS-related information and how to access stored MMS- 
related information on a smart card, in particular on a SIM, a USIM on a UICC, a WIM or a MMC. 

[0012] The invention's advantage lies in a much more sophisticated user experience of the MMS service. The present 
55 invention allows a user of the MMS service to have consistent access to his MMS-related information independent of 
whatever terminal/device he uses at a certain point of time. For example, the user may be notified about an MM (Mul- 
timedia Message) coming in but has no time to view or listen to the MM. He then may take out the MM stored on the 
storage medium and plug it into a computer to view or listen to the MM. If the MM contains e.g. a song the user might 
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listen to it on a music player (adapted to read the format of the song). The user also may extract the MM from another 
mobile communication apparatus than the one he had in use when he was notified of the MM. For originating and 
sending an MM the user may first compose the MM on a terminal of a mobile communication apparatus or a computer 
or any suitable apparatus and store the MM on a storage medium. He then can remove the storage medium from this 
5 apparatus and send it later from another suitable apparatus, said storage medium then connected to the latter appa- 
ratus. 

[0013] Therefore, the invention proposes to provide storage possibilities for MMS-related information, preferably on 
the SIM or on the USIM on the UICC or on any other medium other than the user's terminal/mobile phone in this 
moment. The invention also proposes respective apparatus which store and/or allow access to such MMS-related 

10 information. Such an apparatus is e.g. a mobile communication apparatus, especially a mobile phone (which may 
include other functionalities, e.g. an organizer). Other embodiments are constituted by external devices, e.g. by a 
laptop, a notebook or an organizer which are connectable to such a mobile communication apparatus for storing the 
MMS-related information on said storage medium. The connection between the mobile communication apparatus and 
the external device may be realized by a cable, by infrared technology or by any other way of communication. 

is [0014] The storage medium according to the invention may also be employed by external apparatus according to 
the invention which may be designed to process the MMS-related information or parts thereof. This can be for example 
a music player adapted to read out an acoustical MM which has been received by a mobile phone and stored on said 
storage medium. The storage medium than can be removed from the mobile phone and put into the music player to 
play the MM. Here, there is no need for a direct connection between the mobile phone and the music player. Another 

20 example for an apparatus according to the invention is e.g. a video player which may read out a video-MM from the 
storage medium. All the apparatus for processing MMs (composing and/or displaying) may also be incorporated into 
a mobile communication apparatus. 

[0015] MMS has several MMS-related information which is necessary for using MMS as messaging service. Impor- 
tant MMS-related information is for example: the MMS notification, the MMS delivery report, the MMS read reply report, 
25 MMS service parameters, the Multimedia Message itself, etc. These are some of the MMS-related information which 
might be stored on the storage medium. 

[0016] Up to now it only has been known to store information which is related to SMS (like a short message itself, 
short message parameters, short message status report, etc.) on SIM-cards. It is known for mobile communication 
systems of the 3 rd generation such as UMTS that the SMS-related information shall be stored on the USIM (the logical 
30 functionality) of the UICC (the physical card). In general, the above mentioned smart cards are plugged into a mobile 
phone and enable a user to use the mobile communication service he has subscribed to. Moreover, user preferences 
and settings as well as user's personal information can be stored on such smart cards. 

[0017] For the storage of several information including the SMS-related information the memory of the SIM-card is 
organized in a known hierarchical file structure shown in Figure 2. There are three file types, namely a master file, 

35 dedicated files and elementary files. These files may be either administrative or application specific. The operating 
system handles the access to the data stored in different files. In case of SMS the SMS related information is stored 
in several elementary files. In Figure 3 the known storage of SMS related information on a USIM is shown. Four ele- 
mentary files on the USIM are dedicated to SMS-related information. These are EF SMS for the storage of short mes- 
sages, EF SMSS for SMS status information, EF SMSR for SMS reports and EF SMSP where SMS parameters are stored. 

40 in a very similar manner SMS-related information is stored on the USIM/ UICC. 

[0018] The invention will be discussed more thoroughly with respect to the drawings. The drawings show: 

Fig. 1 an MMS reference architecture according to the state of the art; 

45 Fig. 2 organization of memory on a SIM according to the state of the art; 

Fig. 3 storage of SMS-related information on a USIM according to the state of the art; 

Fig. 4 an example of MMS transaction flows according to the state of the art; 

50 

Fig. 5 an example of an elementary file (EF MMSP ); 

Fig. 6 the parameter indicators of the file according to Fig. 5, and 

55 Fig. 7 storage of MMS-related information on a USIM according to one embodiment of the invention. 

[001 9] In order to describe the MMS-related information that is referred to throughout this document, the MMS service 
is roughly explained. Figure 4 shows a known example of transaction flows of sending an MM from one User Agent 
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(OJJA) to another User Agent (RJJA). The originator MMS User Agent (O-UA) would send an MM by submitting it to 
the originator MMS Relay/Server (O-RS) using the message MM1_send.REQ (MM1_SQ). The originator MMS Relay/ 
Server acknowledges the submission with message MM1_send.RES (MM1_SR). The MM will be routed forward by 
the originator MMS Relay/Server (O-RS) using message MM4_forward.REQ (MM4_FQ) to the recipient MMS Relay/ 
5 Server (R-RS). The recipient MMS Relay/Server (R-RS) acknowledges this with message MM4_forward.RES 
(MM4_FR). After this the recipient MMS Relay/Server (R-RS) sends a notification MM1 notification. REQ (MM1_NQ) 
to the recipient MMS User Agent (R-UA), which acknowledges with message MM1_notification.RES (MM1_NR). With 
this notification the recipient MMS Relay/Server (R-RS) informs the recipient MMS User Agent (R-UA) about a new MM . 
[0020] An example of an MMS notification can be as follows: 

10 

X-Mms-Message-Type: m-send-request 
X-Mms-Transaction-ID: 10 
X-Mms-MMS-Version: 1.0 
From: markus.trauberg@sal.siemens.de 
is Subject: A multimedia message 

X-Mms-Message-Class: Personal 
X-Mms-Message-Size: 52000 
X-Mms-Expiry: 36000 

X-Mms-Content- Location: http://siemens.de/sal/mms-id 

20 

[0021] In hexadecimal code after binary encoding according to WAP-209-M MS Encapsulation (WAP-209-MMSEn- 
capsulation, Version 17): 
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Table 1: Example of an MMS notification in hexadecimal code 

after binary encoding. 



40 [0022] To retrieve the MM, the recipient MMS User Agent (R-UA) requests this MM from the recipient MMS Relay/ 
Server (R-RS). This recipient MMS Relay/Server response with message MM1_retrieve.REQ (MM1_RQ). In a re- 
sponse to this request the recipient MMS Relay/Server (R-RS) delivers the MM to the recipient MMS User Agent with 
message MM1_retrieve.RES (MM1_RR). The recipient User Agent (R-UA) acknowledges the successful reception of 
the MM by sending a message MM1_acknowledge.REQ (MM1_AQ) to the recipient MMS Relay/Server (R-RS). The 

45 recipient MMS Relay/Server (R-RS) may create a delivery report and send it with message MM4_delivery_report.REQ 
(MM4_DRQ) to the originator MMS Relay/Server (O-RS). The originator MMS Relay/Server conveys this delivery report 
to the originator User Agent (O-UA) with message MM1_delivery_report (MM1_DRQ). In addition, e.g. after rendering 
the MM to the user the recipient User Agent (R-UA) may send a read-reply report with message 
M M1 _read_reply_recipient. REQ (MM1_RRQ_R) to the recipient MMS Relay/Server (R-RS). The recipient MMS Relay/ 

so Server (R-RS) routes the read-reply report with message MM4_read_reply_report.REQ (MM4_ RRQ) forward to the 
originator MMS Relay/Server (O-RS) which conveys it further to the originator MMS User Agent with message 
MM1_read_repIy_originator.REQ (MM1_ RRQ_0). 

[0023] According to one preferred embodiment of the present invention MMS-re!ated information can be stored on 
one or several smart cards. Plugged into a mobile phone these smart cards enable a user to use the MMS service he 
55 has subscribed to. User preferences for the MMS service and settings as well as the user's personal information can 
be stored on such smart cards. 

[0024] One preferred possibility according to this invention is storing and/or accessing the MMS-related information 
on a general smart card (i.e. other than WIM, SIM or USIM on an UICC) which can be plugged into a terminal. Such 
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a smart card is preferably a multimedia card (MMC). The advantage of this is that the data is available to a user in a 
consistent manner independent of the terminal he uses. Another advantage is that, in general, an MMC offers much 
more storage capacities than a WIM, SIM or a USIM/UICC. An MMC allows e.g. even for the storage of several entire 
Multimedia Messages (which can exceed many kilobytes, even megabytes of data each). 

5 [0025] Another preferred embodiment of the invention, which already has been mentioned above, is the storage on 
the SIM or on the USIM of the UICC or on a combination of storage on the SIM/USIM on the UICC and the terminal. 
The MMS-related information can be stored in several files, e.g. elementary files(EFs), dedicated files (DFs) or master 
file (MF) on the SIM card or on the USIM application of a UICC card, which per definition can be plugged into a mobile 
phone (note, that the MMS-related information in EFs and/or DFs and/or the MF advantageously can also be stored/ 

10 accessed in other storage media according to the invention). The advantage of this proposal is that the information is 
available to a user in a consistent manner independent of the terminal he uses. Another advantage is that a SIM or a 
UICC is always available in every single GSM or UMTS phone. I.e., this preferred embodiment ensures that the file 
format used for the MMS information and the mechanisms to access this information are understood by every single 
MMS-capable GSM or UMTS phone - independent of the terminal's manufacturer - for the file formats and access 

15 conditions are standardized for the SIM and the USIM/UICC. This is the reason why this proposal is one preferred 
solution. 

[0026] Storing of the MMS related data in several EFs preferably can be done in three different ways according to 
this invention. In the following the storage on the USIM on the UICC is described. Note, that the mechanisms for storing 
and accessing MMS-relevant information on a SIM, on a Multimedia Card or on any other type of smart card preferably 
20 are identical to the mechanisms on the USIM. The following three different cases will be discussed: 

I. Storage of MMS-related information in several (elementary) files. 

II. Storage of MMS-related information in one universal/generic (elementary) file. 
II. Storage of the MMS notification in the existing (elementary) file EF SMS . 

25 

[0027] These different storage principles will now be discussed in more detail. 

I. Storage of MMS-related Information in several files 

30 [0028] The first preferred embodiment proposed for the storage of MMS-related information is the storage in several 
files. For every important MMS information it is proposed to have a separate elementary file. In this example seven 
new elementary files are described. These files are (the names are chosen only by way of example) : 





a) 


EF MMSN 


| Elementary file for the MMS notification. 


35 


b) 


EF MM 


j Elementary file for the Multimedia Message. 




c) 


EF MMSS 


! Elementary file for the MMS status. 




d) 


EF MMSP 


j Elementary file for the MMS parameters. 




e) 


EF MMSDR 


j Elementary file for the MMS delivery report. 


40 


0 


EF MMSRR 


j Elementary file for the MMS read reply report. 




9) 


EF MMSL 


j Elementary file for the MMS size limitations. 



[0029] Furthermore, changes are proposed to the USIM service table (EF UST ) which allows the USIM to indicate 
available services. 

45 

a) EF MMSN (MMS notification) 

[0030] This EF preferably comprises information in accordance with 3GTS 23.140 (3GPPTS 23.140 V4.2.0 (Release 
4), Multimedia Messaging Service (MMS); Functional description; stage 2) and WAP-209-MMSEncapsulation com- 
so prising MMS notifications (and associated parameters) which have been received by the UA from the MMS Relay/ 
Server. With an MMS notification the MMS Relay/Server informs the UA of a recipient user about the arrival of a new 
MM. In particular the notification contains the information where the user can find that MM for downloading it from the 
network. Based on this information the recipient is able to retrieve the MM from the MMS Relay/Server at a later point 
in time. 

55 [0031] Moreover, in case the sender has requested to get feedback information on the status of delivery for that MM 
(delivery report) the notification may contain information about this request. Based on this information in the notification 
the recipient user may decide to allow or disallow the MMS Relay/Server to create such a delivery report. 
[0032] The advantage of storing the MMS notification on the (U)SIM (or any other storage medium according to the 
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invention) is that the user has consistent access to received MMS notifications and their status independent of whatever 
terminal/device he uses at a certain point of time. 

[0033] Table 2 shows the preferred structure of every single record (an entry) of said elementary file. 



Identifier: ' 6FD0' 


Structure: Linear fixed 


Optional 


Record length: 1+A bytes 


Update activity: low 



10 



15 



20 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 



Description 



M/O 



Length 



Status 



M 



1 byte 



2 to A+l MMS Notification 



M 



A bytes 



Table 2: EF for MMS Notification 



25 [0034] According to this invention this EF has the following preferred structure: 

[0035] Assigned to every EF is an "identifier" which addresses a file in the USIM and is 2 bytes long. All the service 
and network related information have addresses beginning with *6F..\ Because of this, the address for this EF with 
MMS-related information is chosen to be an address beginning with *6F..\ The "structure" of the file means which file 
structure is used. The file can be transparent, linear fixed, linear variable or linear cyclic. In this case it is chosen to be 

30 linear for a sequence of records is needed and fixed. The size of every record (an entry in the elementary file) - which 
is "A+1 " octets in the Table 2 - has to be the same. 

[0036] Note: For most of the MMS-related information does not have a well-defined size, but the value of "A" would 
need to be predefined. Using linear fixed files means that the storage capacity of the elementary file can not be used 
the most efficient way. For notifications that are shorter than "A+1" octets still "A+1 " octets would be reserved (but not 

35 used) while notifications that are longer than "A+1" octets would need to be cut off. A second proposal is thus to use 
a linear variable file structure for the EFs. In this case every record has a variable length, which saves storing capacity. 
From a technical point of view a linear variable file structure is thus preferred. However, both, SIM and USIM only 
support linear fixed file structures. Thus, this invention prefers the first solution. For records that are not completely 
filled with MMS-related data, subsequent octets following the MMS-related data shall be filled with 'FF\ This note 

40 applies also to all other elementary files further down! 

[0037] The EF MMSN can be optional or mandatory. In this case it is chosen to be "optional", because MMS will be an 
optional feature on 3G mobile phones. The next parameter is the "record length", which contains the total file length 
in bytes. The "update activity" can be low or high. In this file the update activity is low, because this EF preferably will 
not be updated as often as for example the keys on the USIM. The file has the following access conditions: For "READ" 

45 and "UPDATE" preferably "PIN" (Personal Identification Number) is used, while that are conditions which the user 
controls. For "DEACTIVATE" and "ACTIVATE" preferably "ADM" is used, because these access conditions are under 
control of the authority which created this file. I.e. the file can be read and updated by the user - to whom the SIM 
grants access by the use of a PIN - while it can only be activated and deactivated by the operator of the mobile network. 
Furthermore, Table 2 indicates which bytes are used for which parameter, a description of the data and the length of 

so the data. 

[0038] EFs described below will preferably have the same structure. 

[0039] According to Table 2, the EF MMSN preferably comprises one or more of the following data: 
1 . Status 

55 

[0040] Preferred contents of "Status": The status byte in the EF MMSN contains information related to the MMS noti- 
fication. These information can be for example: 
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• The MM S notification is received by the UA from the M MS Relay/Server, is stored in the EF MMSN on the US I M (or 
another storage medium according to invention; without limitation the following explanation refers to an USIM), 
but has not been read by the user yet (i.e. MMS Notification to be read). 

s • The MMS notification received by the UA from the MMS Relay/Server, is stored in the EF MMSN on the USIM and 
the notification has been read by the user. 

• In the case that the MMS notification received by the UA from the MMS Relay/Server is stored in the EF MMS n on 
the USIM and the notification has been read by the user there are some possibilities according to delivery report 

10 related information: 

o A delivery report has not been requested by the sender of the MM which the notification refers to. 

o A delivery report has been requested by the sender and in a response to this notification the recipient has 

permitted the MMS Relay/Server to create this delivery report. 
15 o A delivery report has been requested by the sender and in a response to this notification the recipient has not 

permitted the MMS Relay/Server to create this delivery report. 

• In the case that the MMS notification received by the UA from the MMS Relay/Server is stored in the EF MMSN on 
the USIM and the notification is read by the user there are some possibilities according to MM retrieval related 

20 information: 

o The MM retrieval has been requested by the recipient, but the MM is not (yet) retrieved, 
o The MM has been retrieved from the MMS Relay/Server by the UA. 

25 [0041] The status byte of the record can be used as a pattern in the SEARCH RECORD command. The SEARCH 
RECORD is a function on the interface between the terminal and the USIM which allows the terminal to search for a 
pattern in various USIM entries. The status preferably will be updated when the UA receives an MMS notification. 
[0042] Preferred coding of "Status": The preferred coding of the status byte is depicted in Table 3 below. 

30 • 1 denotes that the corresponding bit is set. 

• 0 means the corresponding bit is NOT set. 

• X indicates that the corresponding bit may be set or not (i.e. the interpretation of the status byte is independent of 
this bit's value). 

35 
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b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



X 
X 
X 



X 
X 



X 
X 



X 
X 
X 



X 

1 



X 
X 



X X 



X 
X 
X 



0 

1 



X 
0 



X 
X 
X 



X X 



0 
0 



X 
X 
0 



1 
1 



1 
1 



0 

1 
1 



Free space 
Used space 

MMS notification received by UA 
from MMS Relay/Server; notification 
to be read 

MMS notification received by UA 
from MMS Relay/Server; notification 
read 

Delivery report related 
information 

delivery report not requested. 

delivery report requested and 

creation of delivery report 

allowed. 

delivery report requested, but 
creation of delivery report not 
allowed. 

MM retrieval related information 
MM retrieval requested but MM 
not (yet) retrieved 
MM retrieved from the MMS 
Relay/Server 
Reserved for future use 



Table 3: Preferred coding of the status byte. 



[0043] When for example the notification, which has been described with respect to Figure 4, is sent from an originator 
MMS User Agent to a recipient User Agent, 

• the MMS notification has been received by the recipient User Agent from the recipient MMS Relay/Server, 

• has been read by the user, 

• the creation of a delivery report has been requested by the originator MMS User Agent (and the recipient MMS 
User Agent has been informed about this request in the notification) 

• and the creation of this delivery report has been allowed by the recipient User Agent, 

the status byte will be "XXX1 1011", i.e. for example "0001 1011" in bit presentation, which is "1B" in hexadecimal 
presentation. The contents of the EFMMSN in hexadecimal presentation will thus be as follows: 
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10 



IB 


OC 


80 


17 


31 


30 


OD 


20 


09 


20 


10 


6D 


61 


72 


6B 


75 


73 


2E 


74 


72 61 


75 


62 


65 


72 


67 


40 


73 


61 


6C 


2E 


63 


69 


65 


6D 


65 


6E 


73 


2E 


64 


65 


00 


15 


41 


20 


6D 


75 


6C 


74 


69 


6D 


65 


64 


69 


61 


20 


6D 


65 


73 


73 


61 


67 


65 


00 


OA 


80 


OE 


CB 


20 


08 


04 


81 


02 


8C 


AO 


03 


68 


74 


74 


70 


3A 


2F 


2F 


73 


69 


65 


6D 


65 


6E 


73 


2E 


64 


65 


2F 


73 


61 


6C 


2F 


6D 


6D 


73 


2D 


69 


64 





































Table 4: Example of an MMS notification. 

15 [0044] The "IB 1 in this record corresponds to the status byte and the other part of this file is identical to the MMS 
notification as given in the chapter "state of the art" above. 

2. MMS Notification 

20 [0045] Preferred contents of "MMS Notification": The A bytes of MMS Notification contain especially the notification 
information about an MM as it has been received from the MMS Relay/Server. 

b) EF MM (Multimedia Message) 

25 [0046] This EF preferably comprises information in accordance with 3GTS 23.1 40 and WAP-209-MMSEncapsulation 
comprising MMs (and preferably associated parameters) which have either been received by the UA from the MMS 
Relay/Server or are UA originated messages. 

[0047] In UA originated messages the sender has the possibility to request feedback information on the status of 
delivery for that MM (delivery report) and/or feedback information on the status of handling/rendering that MM on the 
30 recipient's UA (read-reply report). After submitting a UA originated MM to the MMS Relay/Server the UA awaits this 
feedback information which has to be matched to this MM. 

UA terminated messages are always retrieved based on information provided in a prior received notification. In case 
the sender of such a UA terminated MM has requested to get feedback information on the status of delivery for that 
MM (delivery report) the MM contains information about this request. Based on this information in the MM the recipient 
35 user may decide to allow or disallow the MMS Relay/Server to create such a delivery report. In case the sender of that 
MM has requested to get feedback information on the status of handling/rendering that MM on the recipient's UA (read- 
reply report) the MM contains information about this request. Based on this information in the MM the recipient user 
may decide to create and send out such a read-reply report. 

[0048] The advantage of storing the MM on the (U)SIM or a WIM is that the user has consistent access to the MM 
40 and its status independent of whatever terminal/device he uses at a certain point of time. 

[0049] Table 5 shows the preferred structure of every single record (an entry) of the elementary file. 
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10 



15 



20 



25 



30 



Identifier: ' 6FD1' 


Structure : Linear fixed 


Optional 


Record length: 1+B bytes 


Update activity: low 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 



2 to B+l MM 



Description 



Status 



M/0 



M 



M 



Length 



1 byte 



B bytes 



Table 5: EF for MM. 
[0050] According to Table 5, the EF MM preferably comprises one or more of the following data: 
1 . Status 

[0051] Preferred contents of "Status": The status byte of the record advantageously can be used as a pattern in the 
SEARCH RECORD command. The status preferably will be updated when the UA receives an MM or has originated 
an MM which is to be stored on a USIM (or a SIM, a WIM, aMMC or another storage medium according to the invention). 
[0052] The status byte in the EF MM contains information related to the MM. These information can indicate for ex- 
ample: 

[0053] In case of UA terminated MM: 



• The MM has been received by the UA from the MMS Relay/Server and is stored in the EF MM on the USIM (or 
another storage medium according to invention; without limitation the following explanation refers to an USIM), 
but has not been read by the user yet (i.e. MM to be read). 

35 

• The MM has been received by the UA from the MMS Relay/Server, has been stored in the EF MM on the USIM and 
the MM has been read by the user. 



• In the case that the MM received by the UA from the MMS Relay/Server is stored in the EF MM on the USIM and 
40 the notification has been read by the user there are some possibilities according to delivery report related infor- 

mation: 



o A delivery report has not been requested by the sender of the MM. 

o A delivery report has been requested by the sender and the recipient has permitted the MMS Relay/Server to 
45 create this delivery report. 

o A delivery report has been requested by the sender and the recipient has not permitted the MMS Relay/Server 
to create this delivery report. 

• In the case that the MM received by the UA from the MMS Relay/Server is stored in the EF MM on the USIM and 
so the MM is read by the user there are some possibilities according to read-reply report related information: 



o A read-reply report for the MM has not been requested by the sender. 

o The read-reply report for the MM has been requested by the sender, but has not yet been created by the 
recipient. 

o The read-reply report has been requested for the MM and this read-reply report has been created by the 

recipient, but has not (yet) been sent out. 
o The read-reply report has been requested for the MM and this read-reply report has been created by the 

recipient and has been sent out. 
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[0054] In case of UA originated MM: 

• An MM has been created by the user, but has not yet been submitted to the MMS Relay/Server. 
5 • An MM has been created by the user and has been submitted to the MMS Relay/Server. 

• In case that the MM has been submitted to the MMS Relay/Server there are the following possibilities according 
to the delivery report: 

10 o A delivery report has not been requested for the MM. 

o A delivery report has been requested for the MM, but it has not (yet) been received. 

o A delivery report has been requested for the MM and this delivery, report has been received, but has not (yet) 
been stored in EF MMSDR . 

o A delivery report has been requested for the MM and this delivery report has been received and is stored in 

15 EF MMSDR- 

• In case that the MM has been submitted to the MMS Relay/Server there are the following possibilities according 
to the read-reply report: 

20 o A read-reply has not been requested for the MM. 

o A read-reply report has been requested for the MM, but has not (yet) been received. 

o A read-reply report has been requested for the MM and this read-reply report has been received, but has not 

(yet) been stored in EF MMSRR . 
o A read-reply report has been requested for the MM and this read-reply report has been received and is stored 

25 in EF MMSRR- 

[0055] Preferred coding of "Status": 



11 




EP 1 255 416 A1 



b8 


b7 


B6 


b5 


b4 


b3 


b2 


bl 



I I I I I I 



X 


X 


X 


X 


X 


0 


Free space 


X 


X 


X 


X 


X 


1 


Used space 


X 


X 


X 


X 


0 


1 


MM received 



by UA from MMS 
Relay/Server 
XXX 0 01 MM to be read 
X X X 1 0 1 MM read 

X X 0 1 0 1 Delivery report related 

information 

0 0 0 10 1 Delivery report not requested 

for the MM 

0 10 10 1 Delivery report requested for 

the MM but not allowed to be 
created 

10 0 10 1 Delivery report requested for 

the MM and allowed to be 
created 

110 10 1 Reserved for future use 

X X 1 1 0 1 Read-Reply report related 

information 

0 0 110 1 Read-Reply report not 

requested for the MM 

0 1110 1 Read-Reply report requested 

for the MM but not (yet) 
created 

10 110 1 Read-Reply report requested 

for the MM/ created, but not 

(yet) sent out 
11110 1 Read-Reply report requested 

for the MM, created and sent 

out 

Reserved for future 
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b8 


B7 


B6 


b5 


b4 


b3 


b2 


bl 



X 
X 



X 



X 
X 



X 
X 



X 
0 



UA originating MM 

MM to be submitted to the MMS 
Relay/Server (draft MM stored on 
the USIM) 

MM submitted to the MMS 
Relay/Server 

Delivery report related 
information 

Delivery report not requested 
for the MM 

Delivery report requested for 
the MM but not (yet) received 
Delivery report requested for 
the MM, received, but not 
stored in EFmmsdr 
Delivery report requested for 
the MM, received and stored 
in EFmmsdr 

Read-Reply report related 

information 

Read-Reply report not 
requested for the MM 
Read-Reply report requested 
for the MM but not (yet) 
received 

Read-Reply report requested 
for the MM, received, but not 
stored in EFmmsrr 
Read-Reply report requested 
for the MM, received and 
stored in EFmmsrr 
Reserved for future use 



Table 6: Preferred coding of the status byte. 
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2. MM 

[0056] Preferred Contents of "MM": The MM contains the entire multimedia message including MM elements/ at- 
tachments. 

5 [0057] Preferred coding of "MM": The MM is preferably coded according to 3G TS 23.140 and WAP-209-MMSEn- 
capsulation. 

c) EF MMSS (MMS status) 

10 [0058] This EF preferably comprises status information relating to the multimedia message service. This file can be 
read by the U A in order to get information about the current memory capacity for the storage of MMS related information 
on the USIM (or any other storage medium according to the invention), like for example MMS notification, MM, MMS 
delivery report, MMS read reply report, etc. This ensures that the maximum memory capacity is not exceeded. This 
information may be used by the UA to inform the MMS Relay/Server about the current memory capacity on the USIM. 

is [0059] When for example a MMS notification is passed from the UA to the USIM, the USIM determines the available 
memory capacity by calculating the difference between the current memory capacity (which is known to the USIM) and 
the size of the incoming data. 

[0060] Table 7 shows the structure of every single record (an entry) of the elementary file. 



20 





Identifier: 1 6FD2 ' 


Structure : Transparent 


Optional 




File size: C+D+E+F+G 


bytes 


Update activity: low 


25 


Access Conditions : 












READ 




PIN 










UPDATE 




PIN 








30 


DEACTIVATE 


ADM 








ACTIVATE 




ADM 










Bytes 


Description 


M/O 


Length 




1 to C 


Message-ID 


M 


C bytes 


35 


C+l to C+D 


MMS notification memory capacity 


M 


D bytes 




C+D+l to 


MM memory capacity 


M 


E bytes 




C+D+E 












40 


C+D+E+l to 


MMS delivery report memory 


M 


F bytes 




C+D+E+F 


capacity 










C+D+E+F+l to 


MMS read reply report memory 


M 


G bytes 




C+D+E+F+G 


capacity 









Table 7: EF for MMS status. 



[0061] According to Table 7, the EF MMSS preferably comprises one or more of the following data: 

50 

1. Message-ID 

[0062] Preferred contents of "Message-ID": The message-ID is a unique reference assigned to the MM. 
[0063] Preferred coding of "Message-ID": The message-ID is coded according to 3G TS 23.140 and WAP- 
55 209-MMSEncapsulation. 
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2. MMS notification memory capacity 

[0064] Preferred contents of "MMS notification memory capacity": The MMS-notification memory capacity contains 
the available memory for MMS-notifications. 
s [0065] Preferred coding of "MMS notification memory capacity": The MMS-notification memory capacity is coded in 
bytes. 

3. MM memory capacity 

10 [0066] Preferred contents of "MM memory capacity": The MM memory capacity contains the available memory for 
MMs. 

[0067] Preferred coding of "MM memory capacity": The MM memory capacity is coded in bytes. 

4. MMS delivery report memory capacity 

15 

[0068] Preferred contents of "MMS delivery report memory capacity": The MMS delivery report memory capacity is 
the available memory for delivery reports. 

[0069] Preferred coding of "MMS delivery report memory capacity": The MMS delivery report memory capacity is 
coded in bytes. 

20 

5. MMS read reply report memory capacity 

[0070] Preferred contents of "MMS read-reply report memory capacity": The MMS read reply report memory capacity 
is the available memory for read reply reports. 
25 [0071] Preferred coding of "MMS read-reply report memory capacity": The MMS read reply report memory capacity 
is coded in bytes. 

d) EF MMSP (MMS parameters) 

30 [0072] This EF preferably comprises values for Multimedia Messaging Service parameters, which can be used by 
the UE (User equipment) for user assistance in preparation of mobile multimedia messages (e.g. default values for 
parameters that are often used) and/or which can be used by the MMS service provider to preconfigure the MMS 
service according to his particular needs. These Multimedia Messaging Service parameters are for example the orig- 
inator address, the recipient address, the MMS Relay/Server address, the expiry time, the earliest time of delivery, the 

35 message class, the sender visibility request, the delivery report request, the read reply report request and the priority. 
[0073] The advantage of storing these parameters on the USIM on the UICC (or any other storage medium according 
to the invention) is for example that several of these parameters will be common for MMs send by the subscriber, i.e. 
the user can define default values and thus experiences a more comfortable service. Moreover the service provider 
may preconfigure certain parameters, which allows for an automated processing of the MMS service by the terminal. 

40 in the latter case the user does not have to set these parameters manually, which again increases the comfort. 
[0074] Table 8 shows the preferred structure of every single record (an entry) of the elementary file. 



45 



50 



55 



15 



EP1 255 416 A1 



Identifier: ' 6FD3 1 


Structure: Linear fixed 


Optional 


Record length: 

H+I+J+K+L+M+N+O+P+Q+R+13 bytes 


Update activity: low 


Access Conditions: 

READ PIN 
UPDATE PIN 
DEACTIVATE ADM 
ACTIVATE ADM 


Bytes 


Description 


M/0 


Length 


1 to H 


Alpha- Identifier 


O 


H bytes 


H+l to H+2 


Parameter Indicators 


M 


2 bytes 


H+3 


MMS Implementation 


M 


1 byte 


H+4 


Length of the originator 
address 


O 


1 byte 


H+5 


Length of the recipient 
address 


0 


1 byte 


H+6 


Length of the MMS 
Re lay/ Server address 


o 


1 byte 


H+7 


Length of the expiry time 


o 


1 byte 


H+8 


Length of earliest time of 
delivery 


0 


1 byte 


H+9 


Length of the message 
class 


0 


1 byte 


H+10 


Length of Sender 
visibility request 


o 


1 byte 


H+ll 


Length of Delivery report 
request 


o 


1 byte 


H+12 


Length of Read reply 
report request 


0 


1 byte 


H+13 


Length of Priority 


o 


1 byte 


H+14 to H+I+13 


Originator address 


o 


I bytes 


H+I+14 to H+I+J+13 


Recipient address 


o 


J bytes 


H+I+J+14 to 
H+I+J+K+13 


MMS Relay/Server address 


0 


K bytes 


H+I+J+K+14 to 


Expiry time 


0 


L bytes 
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H+I+J+K+L+13 








5 


H+I+J+K+L+14 to 
H+I+J+K+L+M+13 


Earliest time of delivery 


0 


M bytes 




H+I+J+K+L+M+14 to 


Message class 


0 


N bytes 




H+ 1+ J+K+L+M+N+ 1 3 








10 


H+ I+J+K+L+M+N+14 to 
H+I+ J+ K+ L+M+N+ 0+13 


Sender visibility request 


0 


0 byte 




H+ 1 + J+ K+ L+M+N+ 0+ 1 4 


Delivery report request 


0 


P byte 


15 


to H+ I-f K+L+M+N+0+ 
P+13 










H+I + J+ K+ L+M+N+ 0+ P+ 


Read reply report request 


0 


Q byte 


20 


14 to 

H+I+J+K+L+M+N+0+ 
P+Q+13 








25 

rtrt 


H+I + J+K-fL+M+N+O+P+Q 
+ 14 to 

H+I + J+K+L+M+N+O+P+Q 
+R+13 


Priority 


0 


R byte 



Table 8: EF for MMS parameters. 



[0075] According to Table 8, the EF MMSP preferably comprises one or more of the following data: 

35 

1 . Alpha-Identifier 

[0076] Preferred contents: The alpha-identifier is an alpha Tag to the associated MMS-parameter. It can be defined 
by the USIM or the USIM application toolkit and if available it should be rendered to the user, i.e. it should be shown 
40 on the display 

[0077] Preferred coding: The alpha-identifier is coded as text string according to 3G TS 23.140 and WAP- 
209-MMSEncapsulation . 

2. Parameter Indicators 

45 

[0078] Preferred contents: The parameters indicators contain the information if the MMS related parameters are 
present or not - see figures 5 and 6. 
[0079] Preferred coding: Allocation of bits: 



Bit number 


Parameter indicated 


1 


Length of originator address 


2 


Length of recipient address 


3 


Length of MMS Relay/Server address 


4 


Length of expiry time 


5 


Length of earliest time of delivery 


6 


Length of message class 



17 




EP1 255 416 A1 



(continued) 



Bit number 


Parameter indicated 


7 


Length of Sender visibility request 


8 


Length of Delivery report request 


9 


Length of Read reply report request 


10 


Length of Priority 


11-16 


Reserved for future use 


Bit value Meaning 


0 


Parameter present. 


1 


Parameter absent. 



15 

3. MMS Implementation 



[0080] Preferred contents: The MMS Implementation contains the used protocol type, e.g. WAP, IP, etc. This infor- 
mation is used to indicate the MMS implementation type and version used for the MMS related information on the 
20 USIM and thus e.g. to ensure backwards compatibility. 
Preferred coding: Allocation of bits: 



Bit number 


Parameter indicated 


1 

2-8 


WAP implementation of MMS according to WAP-209-MMSEncapsulation, Version 17 
Reserved for future use 


Bit value Meaning 


0 
1 


Implementation not supported. 
Implementation supported. 



4. Length of the originator address 

[0081] Preferred contents: The length of the originator address contains the length of the originator address. 
35 [0082] Preferred coding: The Length of the originator address is coded in bytes. 

5. Length of the recipient address 

[0083] Preferred contents: The length of the recipient address contains the length of the recipient address. 
40 [0084] Preferred coding: The length of the recipient address is coded in bytes. 

6. Length of the MMS Relay/Server address 

[0085] Preferred contents: The length of the MMS Relay/Server address contains the length of the address of the 
4 5 MMS Relay/Server. 

[0086] Preferred coding: The length of the MMS Relay/Server address is coded in bytes. 

7. Length of the expiry time 

so [0087] Preferred contents: The length of the expiry time contains the length of the expiry time. 
[0088] Preferred coding: The length of the expiry time is coded in bytes. 

8. Length of the earliest time of delivery 

55 [0089] Preferred contents: The length of the earliest time of delivery contains the length of the earliest time of delivery. 
[0090] Preferred coding: The length of the earliest time of delivery is coded in bytes. 
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9. Length of the message class 

[0091] Preferred contents: The length of the message class contains the length of the message class. 
[0092] Preferred coding: The length of the message class is coded in bytes. 

5 

1 0. Sender visibility request 

[0093] Preferred contents: The sender visibility request contains the request if the address/phone number of the 
sender to the recipient is shown unless the sender has a secret number. This is used for user assistance in the MM 
10 composition. 

[0094] Preferred coding: The sender visibility request is coded according to 3G TS 23.140 and WAP-209-MMSEn- 
capsulation. 

11. Delivery report request 

15 

[0095] Preferred contents: The delivery report request contains the information if the delivery report is requested. 
This is used for user assistance in the MM composition. 

[0096] Preferred coding: The delivery request is coded according to 3G TS 23.140 and WAP-209-MMS Encapsula- 
tion. 

20 

1 2. Read reply report request 

[0097] Preferred contents: The read reply report request contains the information if the read reply report is requested. 
This is used for user assistance in the MM composition. 
25 [0098] Preferred coding: The read reply report is coded according to 3G TS 23.1 40 and WAP-209-MMS Encapsula- 
tion. 

13. Priority 

30 [0099] Preferred contents: The priority contains the priority (importance) of the message. This is used for user as- 
sistance in the MM composition. 

[0100] Preferred coding: The priority is coded according to 3G TS 23.140 and WAP-209-MMSEncapsuIation. 

14. Originator address 

35 

[0101] Preferred contents: The originator address contains the address of the originator. This originator address can 
be an MSISDN (Mobile Subscriber Integrated Services Digital Network Number, an e-mail address or other operator 
specific addresses. This parameter can be used by the service provider to preconfigure the MMS service and it can 
be used for user assistance in the MM composition. 
40 [0102] Preferred coding: The originator is coded according to 3G TS 23.140 and WAP-209-M MS Encapsulation. 

15. Recipient address 

[0103] Preferred contents: The recipient address contains the address of the recipient. This recipient address can 
45 be an MSISDN (Mobile Subscriber Integrated Services Digital Network Number, an e-mail address or other operator 
specific addresses. This can be used for user assistance in the MM composition. 

[0104] Preferred coding: The recipient is coded according to 3G TS 23.140 and WAP-209-MMSEncapsulation. 

16. MMS Relay/Server address 

50 

[0105] Preferred contents: The MMS Relay/Server address contains the address of the MMS Relay/Server. This 
parameter can be used by the service provider to preconfigure the MMS service. This address can be a configurable 
URI (Uniform Resource Identifier) and is given by the MMS Service Provider. It is necessary for the UA to know the 
address of the MMS Relay/Server, because the UA has to know where to submit MMs and MMS read-reply reports to. 
55 [0106] Preferred coding: The MMS Relay/Server is coded according to 3G TS 23.140 and WAP-209-MMSEncapsu- 
lation. 
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17. Expiry time 

[0107] Preferred contents: The expiry time contains the length of the time that the message is available. This pa- 
rameter can be used by the service provider to preconfigure the MMS service and it can be used for user assistance 
5 in the MM composition. 

[0108] Preferred coding: The expiry time is coded according to 3G TS 23.140 and WAP-209-MMSEncapsulation. 

18. Earliest time of delivery 

10 [0109] Preferred contents: The earliest time of delivery is the earliest time that the message is delivered. This pa- 
rameter can be used by the service provider to preconfigure the MMS service and it can be used for user assistance 
in the MM composition. 

[0110] Preferred coding: The earliest time of delivery is coded according to 3G TS 23.140 and WAP-209- MMS En- 
capsulation. 

15 

1 9. Message class 

[0111] Preferred contents: The message class contains the class of the multimedia message. This message class 
can be for example personal, advertisement, information service, etc. This is used for user assistance in the MM 
20 composition. 

[01 12] Preferred coding: The message class is coded according to 3G TS 23. 1 40 and WAP-209-M MS Encapsulation. 
[01 13] In Figure 5 an example of this EF MMSP is shown to describe the functionality of the parameter indicators. The 
bit structure of the 2 bytes long "Parameter Indicators" of Fig. 5 is also shown in Figure 6. 

[0114] In this example, bit 1 , 2 and 3 of the parameter indicators equal "1 ", which means that the length of the 1 st , 
25 2 nd and 3 rd parameters - length of originator address, length of the recipient address and the length of the MMS Relay/ 
Server address (and thus implicitly also the originator address, the recipient address and the MMS Relay/Server ad- 
dress) - are present. The other bitsequal "O", which means that all other parameters are absent. 

e ) ef mmsdr ( MMS delivery report) 

30 

[0115] This EF preferably comprises information in accordance with 3GTS 23.140 and WAP-209-MMSEncapsulation 
comprising multimedia message delivery reports which have been received by the UA from the MMS Relay/Server. 
For every delivery report corresponds to an MM this EF also refers to that associated MM. 

[0116] Each record is preferably used to store the delivery report of a previously submitted MM in a record of EF MM . 
35 The first byte of each record is preferably the link between the delivery report and the corresponding MM in EF MM . 
Table 9 shows the preferred structure of every single record (an entry) of the elementary file. 



40 


Identifier: 1 


6FD4 f 


Structure : 


Linear fixed 


Optional 




Record length 


: 1 + S 


bytes 


Update activity: 


low 




Access Conditions : 












45 


READ 
UPDATE 




PIN 
PIN 












DEACTIVATE 


ADM 










50 


ACTIVATE 




ADM 










Bytes 1 


Description 


M/O 


Length 




1 


MMS delivery record 


M 




1 






identifier 










55 


2 to S+l 


MMS delivery report 


M 


S bytes 



Table 9: EF for MMS delivery report. 
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[0117] According to Table 9, the EF MMSDR preferably comprises one or more of the following data: 
1 . MMS delivery record identifier 

[0118] Preferred contents: The MMS delivery record identifier identifies the corresponding MM record in EF MM , e.g. 
if this byte is coded '05' then this delivery report corresponds to the MM in record #5 of EF MM . 
[01 19] Preferred coding: 



•00' 

•OV-'FF 



empty record. 

record number of the corresponding MM in EF MM . 



2. MMS delivery report 



[0120] Preferred contents: The MMS delivery report contains the MMS-DELIVERY-REPORT as specified in 3G TS 
23.140 and WAP-209-MMS Encapsulation, preferably with identical coding and ordering of parameters. 
[0121] Preferred coding: The MMS delivery report is coded according to 3G TS 23.140 and WAP-209-M MS Encap- 
sulation. 



f ) ef mmsrr (MMS read reply report) 

[01 22] This E F preferably comprises information in accordance with 3G TS 23. 1 40 and WAP-209-M MSEncapsulation 
comprising multimedia message read reply reports which have been received by the UAfrom the MMS Relay/Server 
or are to be used as an UA originated message. For every read-reply report corresponds to an MM this EF also refers 
to that associated MM. 

[0123] Each record is preferably used to store the read reply report to an MM in a record of EF MM . The first byte of 
each record is the link between the read reply report and the corresponding MM in EF MM . Table 1 0 shows the preferred 
structure of every single record (an entry) of the elementary file. 
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Identifier: f 6FD5' 


Structure: Linear fixed 


Optional 


Record length: T+l bytes 


Update activity: low 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 



2 to T+l 



Description 



MMS read reply record 
identifier 



MMS read reply report 



M/O 



M 



M 



Length 



T bytes 



Table 10: EF for MMS read reply report. 

[0124] According to Table 1 0, the EF MMSRR preferably comprises one or more of the following data: 
1 . MMS read reply record identifier 

[0125] Preferred contents: The MMS read reply record identifier identifies the corresponding MM record in EF MM , e. 
g. if this byte is coded '05' then this read reply report corresponds to the MM in record #5 of EF MM . 
[0126] Preferred coding: 



21 



EP 1 255 416 A1 



10 



15 



20 



25 



'00' 

•or 



•fp 



empty record. 

record number of the corresponding MM in EF MM . 



2. MMS read reply report 

[0127] Preferred contents: The MMS read reply report contains the MMS-READ_REPLY-REPORT as specified in 
3G TS 23.140 and WAP-209-MMSEncapsulation, preferably with identical coding and ordering of parameters. 
[0128] Preferred coding: The MMS read reply report is coded according to 3G TS 23.140 and WAP-209-MMSEncap- 
sulation. 

g) EF MMSL (MMS size limitations) 

[0129] This EF preferably comprises values for Multimedia Messaging Service header limitations, which can be 
defined by the authority that owns the USIM/UICC (in general the network operator). 

[0130] For the USIM only supports a linear fixed file structure (see explanations above), the authority that owns the 
USIM/UICC needs to define a maximum length of each record (of every file). MMS-related information, however, is 
not limited to a certain size. Thus, there are no MMS-inherent pre-settings for the maximum length of MMS-related 
records. 

[0131] This invention thus proposes an EF MMSL wherein the authority that owns the USIM/UICC defines the maximum 
length of MMS-related records in a manner appropriate to this authorities needs. This EF can be read by a terminal 
(where the USIM/UICC is plugged in to) upon booting the card in order to be informed of the authorities settings. 
According to these settings the terminal then has to cut MMS-related information in case these exceed the limitations. 
[0132] Table 11 shows the preferred structure of every single record (an entry) of the elementary file EF MMSL . 



Identifier: 1 6FD6' 


Structure: Linear fixed 


Optional 


Record length: 14 bytes 


Update activity: low 



30 



35 



40 



45 



50 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 


Description 


M/O 


Length 


1 to 2 


Length of a record in EFmmsn 


O 


2 bytes 


3 to 6 


Length of a record in EFmm 


o 


4 bytes 


7 to 8 


Length of a record in EFmmss 


0 


2 bytes 


9 to 10 


Length of a record in EFmmsp 


0 


2 bytes 


11 to 12 


Length of a record in EFmmsdr 


0 


2 bytes 


13 to 14 


Length of a record in EFmmsrr 


0 


2 bytes 



Table 11: EF for MMS limitations. 



55 



[0133] According to Table 11 , the EF MMSL preferably comprises one or more of the following data: 
1 . Length of a record in EF MMSN (MMS notification) 

[0134] Preferred contents/preferred coding: Defines the length of a record in EF MMSN , i.e. the maximum size of an 
MMS notification that can be stored on the USIM, which is 1+A (see above), in bytes. For the length of a record in 
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EF MMSN is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

2. Length of a record in EF MM (Multimedia Message) 

s [0135] Preferred contents/preferred coding: Defines the length of a record in EF MM , i.e. the maximum size of a Mul- 
timedia Message that can be stored on the USIM, which is 1+B (see above), in bytes. For the length of a record in 
EF MMSN is encoded as a 4 byte number, the maximum possible value is 4 Giga-Byte. 

3. Length of a record in EF MMSS (MMS status) 

10 

[0136] Preferred contents/preferred coding: Defines the length of a record in EF MMSS , i.e. the maximum size of an 
MMS status entry that can be stored on the USIM, which is C+D+E+F+G (see above), in bytes. For the length of a 
record in EF MMSS is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

15 4. Length of a record in EF MMSS (MMS status) 

[0137] Preferred contents/preferred coding: Defines the length of a record in EF MMSS> i.e. the maximum size of an 
MMS status entry that can be stored on the USIM, which is C+D+E+F+G (see above), in bytes. For the length of a 
record in EF MMSS is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

20 

5. Length of a record in EF MMSP (MMS parameter) 

[0138] Preferred contents/preferred coding: Defines the length of a record in EF MMSP , i.e. the maximum size of an 
MMS parameter entry that can be stored on the USIM, which is H+l+J+K+L+M+N+O+P+Q+R+1 3 (see above), in bytes. 
25 For the length of a record in EF MMSP is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

6. Length of a record in EF MMSDR (MMS delivery report) 

[0139] Preferred contents/preferred coding: Defines the length of a record in EF MMSDR , i.e. the maximum size of an 
30 MMS delivery report that can be stored on the USIM, which is 1+S (see above), in bytes. For the length of a record in 
EF MMSDR is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

7. Length of a record in EF MMSRR (MMS read-reply report) 

35 [0140] Preferred contents/preferred coding: Defines the length of a record in EF MMSRR , i.e. the maximum size of an 
MMS read-reply report that can be stored on the USIM, which is 1 +T (see above), in bytes. For the length of a record 
in EFMMSRR is encoded as a 2 byte number, the maximum possible value is 64 kbyte. 

h) EF UST (USIM Service Table) 

40 

[0141] This EF indicates to a UE which services are available in a USIM. If a service is not indicated as available in 
the USIM, the UE shall not select this service. From the USIM Service Table a UE can immediately retrieve the infor- 
mation whether or not a USIM supports the MMS service. 

[0142] Table 1 2 shows the preferred structure of every single record (an entry) of the elementary file. 

45 



50 



55 
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Identifier: 1 6F38 1 


Structure : transparent 


Mandatory 


SFI: »04 T 




File size: X bytes, X >= 1 


Update activity: low 


Access Conditions: 

READ PIN 
UPDATE ADM 
DEACTIVATE ADM 
ACTIVATE ADM 


Bytes 


Description 


M/O 


Length 


1 


Services n°l to n°8 


M 


1 byte 


2 


Services n°9 to n°16 


0 


1 byte 


3 


Services n°17 to n°24 


0 


1 byte 


4 


Services n°25 to n°32 


0 


1 byte 


etc . 








X 


Services n°(8X-7) to n° (8X) 


0 


1 byte 



Table 12: EF for the USIM service table. 



[0143] The Services n°1 to n°50 may have the content as listed in Table 13. Here, the Services n°44 to n°50 refer 
30 to MMS-related information of which one or more preferably are included in said elementary file according to the in- 
vention. 



Table 13: 



Preferred services of the USIM service table. 


Services 




: 
: 
: 


contents 


Service n°1 


I Local Phone Book 




Service n°2 


j Fixed Dialing Numbers (FDN) 




Service n°3 


I Extension 2 




Service n°4 


j Service Dialing Numbers (SDN) 




Service n°5 


j Extension3 




Service n°6 


| Barred Dialing Numbers (BDN) 




Service n°7 


| Extension4 




Service n°8 


j Outgoing Call Information (OCI and OCT) 




Service n°9 


| Incoming Call Information (ICI and ICT) 




Service n°10 


| Short Message Storage (SMS) 




Service n°11 


! Short Message Status Reports (SMSR) 




Service n°12 


| Short Message Service Parameters (SMSP) 




Service n°13 


j Advice of Charge (AoC) 




Service n°14 


I Capability Configuration Parameters (CCP) 




Service n°15 


j Cell Broadcast Message Identifier 




Service n°16 


j Cell Broadcast Message Identifier Ranges 




Service n°17 


I Group Identifier Level 1 




Service n°18 


j Group Identifier Level 2 




Service n°19 


! Service Provider Name 




Service n°20 


I User controlled PLMN selector with Access Technology 
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Table 13: (continued) 





Preferred services of the USIM service table. 






Service n°21 


MSISDN 


5 




Service n°22 


Image (IMG) 






Service n°23 


Not used (reserved for SoLSA) 






Service n°24 


Enhanced Multi-Level Precedence and Pre-emption Service 






Service n°25 


Automatic Answer for Emlpp 






Service n°26 


RFU 


10 




Service n°27 


GSM Access 






Service n°28 


Data download via SMS-PP 






Service n°29 


Data download via SMS-CB 






Service n°30 


Call Control by USIM 


15 




Service n°31 


MO-SMS Control by USIM 






Service n°32 


RUN AT COMMAND command 






Service n°33 


Packet Switched Domain 






Service n°34 


Enabled Services Table 






Service n°35 


APN Control List (ACL) 


20 




Service n°36 


Depersonalization Control Keys 






Service n°37 


Co-operative Network List 






Service n°38 


GSM security context 






Service n°39 


CPBCCH Information 


25 




Service n°40 


Investigation Scan 






Service n°41 


MexE 






Service n°4P 

^-J w 1 V Iww 1 1 "L 


Ooerator controlled PLMN selector with Access Technoloav 






Service n°43 


HPLMN selector with Access Technology 






Service n° 44 


Multimedia Message Notification 


30 




Service ft 45 


Multimedia Message Service Storage 






Service n°46 


Multimedia Message Service Delivery Report 






Service n°47 


Multimedia Message Read Reply Report 






Service n°48 


Multimedia Message Parameters 


35 




Service n°49 


Multimedia Message Service Status 




Service n°50 


Multimedia Message Service Limitations 



[0144] The EF shall contain at least one byte. Further bytes may be included, but if the EF includes an optional byte, 
then it is mandatory for the EF to also contain all bytes before that byte. Other services are possible in the future and 
40 will be coded on further bytes in the EF. 
[0145] Preferred coding: 
[0146] 1 bit is used to code each service: 

bit = 1 : service available; 
45 bit = 0: service not available. 

[0147] Service available means that the USIM has the capability to support the service and that the service is available 
for the user of the USIM unless the service is identified as "disabled" in EF EST , another elementary file on the USIM. 
[0148] Service not available means that the service shall not be used by the USIM user, even if the USIM has the 
50 capability to support the service. 

[0149] The preferred coding of each byte in EF UST is shown in Tables 14 and 15. 
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First byte: 
[0150] 



b8 


b7 


b6 


b5 


b4 


B3 


b2 


bl 



Service n°l 
Service n°2 
Service n°3 
Service n°4 
Service n°5 
Service n°6 
Service n°7 
Service n°8 



Table 14: Preferred coding of the first byte of the USIM 

service table. 



Second byte: 
[0151] 



b8 


bl 


b6 


b5 


b4 


b3 


b2 


bl 



| Service n°9 

Service n°10 

Service n°ll 

Service n°12 

Service n°13 

Service n°14 

Service n°15 

Service n°16 



Table 15: Preferred coding of the second byte of the USIM 

service table. 

etc. 

With regard to the Services n°44 to n°50 of Table 13: 

[0152] The Parameter "Multimedia Message Notification" indicates whether EF MMSN is supported on the USIM. 
[0153] The Parameter "Multimedia Message Service Storage" indicates whether EF MM is supported on the USIM. 
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[0154] The Parameter 'Multimedia Message Service Delivery Report" indicates whether EF MMSDR is supported 
on the USIM. 

[0155] The Parameter n Multimedia Message Read Reply Report" indicates whether EF MMSRR is supported on the 
USIM. 

5 [0156] The Parameter 'Multimedia Message Parameters" indicates whether EF MMSP is supported on the USIM. 
[01 57] The Parameter "Multimedia Message Service Stat us "indicates whether EF MMSS is supported on the USIM . 
[0158] The Parameter "Multimedia Message Service Limitations" indicates whether EF MMSL is supported on the 
USIM. 

[0159] Figure 7 shows an example how storage of MMS related information on the USIM can be achieved according 
10 to this first preferred mechanism described above. The elementary files proposed above that contain MMS-related 
information are marked as bold boxes. 



II. Storage of MMS related information in one universal file 



is [0160] The second preferred embodiment is the storage of MMS-related information in one universal/generic file 
dedicated to MMS. All the MMS related information preferably will be saved in one universal/generic file. The advantage 
of using one universal/generic file is the optimization of the used memory. Table 16 shows the preferred structure of 
every single record (an entry) of the elementary file EF MMS . 



20 



40 



Identifier: » 6FD5' 


Structure: Linear fixed 


Optional 


Record length: U+2 bytes 


Update activity: low 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 



3 to U+2 



Description 



Status 



Message type 



Message 



M/O 



M 



M 



M 



Length 



1 byte 



1 byte 



U bytes 



Table 16: Universal EF for MMS related information. 



[0161] According to Table 16, the EF MMS preferably contains one or more of the following data: 
45 1 . Status 



[0162] The preferred contents and preferred coding of the Status is according to the example of the EF MMSN . 
2. Message type 

50 

[0163] Preferred contents: The message type contains the information which message type is used. Possible mes- 
sage types are shown - together with their preferred encoding - in Table 17. 
[0164] Preferred coding: 



27 



EP1 255 416 A1 



b8 


b7 


b6 


b5 


B4 


b3 


b2 


bl 



10 



15 



X 
X 
0 
0 
0 
0 



X 
X 
0 
0 

1 
1 



X 
X 
0 

1 

0 

1 



0 Free space 

1 Used space 

1 MMS notification 
1 MM 

1 Delivery report 
1 Read reply report 
Reserved for future 



Table 17: Preferred coding of the message type, 

20 

3. Message 



[0165] Preferred contents: The message content is the information of the selected message type according to the 
description of that message type in example I. 
25 [0166] Preferred coding: The coding of the selected message type is in accordance to the description of that message 
type described in example I. 

[0167] For this second proposal it is seen valuable to have EF UST , EF MMSP and EF MMSS in addition to EF MMS as in 
the first proposal. 



30 III. Storage of the MMS notification in EF SMS 



[0168] The third preferred embodiment is the storage of the MMS notification in EF SMS , an elementary file used for 
the storage of short messages (SMS). At least in the early beginnings of MMS, notifications will be sent encapsulated 
in a short message. This is why MMS notifications can be stored in EF SMS . 
35 [0169] The advantage of this proposal is that the existing file structure of the USIM can be used unchanged. The 
disadvantage is that other important MMS related information can not be stored. 

[01 70] The elementary file EF SMS (Short messages) preferably contains information in accordance with 3GTS 31.101 
(3GPPTS 31.101 V3.3.0, UlCC-Terminal Interface; Physical and Logical Characteristics) comprising short messages 
(and associated parameters) which have either been received by the UE from the network, or are to be used as an 
^o UE originated message. Table 1 8 shows the preferred structure of every single record (an entry) of the elementary file. 
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10 



15 



20 



25 



Identifier: T 6F3C' 


Structure: linear fixed 


Optional 


Record length: 176 bytes 


Update activity: low 



Access Conditions : 

READ PIN 

UPDATE PIN 

DEACTIVATE ADM 

ACTIVATE ADM 



Bytes 



2 to 176 



Description 



Status 



Remainder 



M/O 



M 



M 



Length 



1 byte 



175 bytes 



Table 18: EF for SMS * 

[0171] The EF SMS preferably contains one or more of the following data: 
1 . Status 

[0172] Preferred contents: The Status byte of the record can be used as a pattern in the SEARCH RECORD com- 
mand. For UE (User Equipment) originating messages sent to the network, the status preferably shall be updated when 
the UE receives a status report, or sends a successful SMS Command relating to the status report. 
[0173] Preferred coding: 
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b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



10 



15 



20 



25 



30 



35 



x X X 0 free space 
XXXI used space 

o 0 0 1 Message received by UE from 

network; message read 
0 0 11 Message received by UE from 

network; message to be read 
0 1 1 1 UE originating message; message to 

be sent 
10 0 1 MMS notification 

Reserved for future (see 

3G TS 31.101 [11] ) 



b8 


b7 


b6 


b5 


b4 


b3 


B2 


bl 



0 
0 



0 

1 



0 
0 



X X 1 0 1 UE originating message; message sent 
to the network: 
1 Status report not requested 
1 Status report requested/ but not 

(yet) received; 
1 Status report requested, received/ 

but not stored in EF-SMSR; 
1 Status report requested, received 
and stored in EF-SMSR; 
RFU (see 3G TS 31.101 [11]) 



10 10 



1 1 



Table 19: Preferred coding for the status byte. 
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50 
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2. Remainder 

[0174] The Remainder is proposed to be as in 3G TS 31 .101. I.e. if a UE receives an MMS notification from the 
network - as long as this notification is carried in a short message (SMS) - the notification can be stored in EF SMS with 
a status byte equal to "0000 1001" in binary presentation, which is "09" in hexadecimal presentation. For this third 
proposal it is seen valuable to have EF UST , EF MMSP and EF MMSS in addition to EF SMS as in the first proposal. 
[0175] In summary, important aspects of the present invention are: 

[0176] Storage/ Accessing of MMS related information or parts of MMS-related information on media different from 
the user's terminal, especially: 

on a SIM or on a USIM on a UICC; 
onaWIM 

on a smart card which is not one of the above, especially an MMC (Multimedia Card); 
a combination of these storage possibilities. 

[0177] The following information preferably are stored on such a repository: 

MMS notifications; 
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entire or parts of a Multimedia Message (MM); 
MMS delivery reports; 
MMS read-reply reports; 
MMS parameters; 
s - MMS status information; 

MMS limitations information (defined by the authority that owns the smart card); 
an indication of the smart card supporting MMS (e.g. in the USIM service table). 

[0178] Three different mechanisms are preferred of how to achieve the storage of MMS-related information and how 
10 to access stored MMS-related information on a smart card, in particular on a SIM or a USIM on a UICC.: 

storage of MMS related information in several elementary files; 
storage of MMS related information in one universal elementary file; 
storage of the MMS notification in the existing elementary file EF SMS . 

15 

Claims 

1 . Method for storing MMS (Multimedia Messaging Service) -related information, characterized In that said informa- 
20 tion is stored on at least one storage medium or a combination of storage mediums connected to a mobile com- 

munication apparatus which supports MMS services or a device connected to such a mobile communication ap- 
paratus, said at least one storage medium or a combination of storage mediums being disconnectable from said 
apparatus or said device. 

25 2. Method for accessing MMS-related information by an apparatus adapted to process said MMS-related information, 
characterized In that said information is accessed on at least one storage medium or a combination of storage 
mediums connected to said apparatus, said at least one storage medium or a combination of storage mediums 
being disconnectable from said apparatus. 

30 3. Method according to claim 1 or 2 characterized in that the MMS-related information is terminal-originated or 
terminal-terminated. 

4. Method according to any one of the preceding claims characterized in that said at least one storage medium is 
a smart card, especially a SIM (Subscriber Identity Module), a USIM (UMTS Subscriber Identity Module) on a 

35 UICC (Universal Integrated Circuit Card), a WIM (Wireless application protocol Identity Module) or an MMC (Mul- 

timedia Card). 

5. Method according to any one of the preceding claims characterized in that one or more of the following MMS- 
related information are stored and/or accessed on said at least one storage medium: 

40 

MMS notifications; 

Entire Multimedia Messages (MM) or parts thereof; 
MMS status information; 
MMS delivery reports; 
45 - MMS read-reply reports; 

MMS parameters; 

MMS limitations information, especially those being defined by the authority that owns the smart card; 
Indication of the MMS-services being available. 

50 6. Method according to any one of the preceding claims characterized in that said information is stored and/or 
accessed in one or more files on said at least one storage medium, especially with these above files being one or 
more elementary files and/or dedicated files and/or the master file. 

7. Method according to any one of the preceding claims characterized In that the files are of transparent, linear 
55 fixed, linear variable or linear cyclic file structure. 

8. Method according to claim 6 or 7 characterized in that the information according to claim 5 each is stored and/ 
or accessed in separate files (EF MMSN , EF MM , EF MMSS , EF MMSP , EF MMSDR , EF MMSRR , EF MMSL , EF UST ) on said 
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at least one storage medium. 

Method according to claim 8 characterized in that said one or more files (EF MMSN , EF MM , EF MMSS , EF MMSP , 
EF MMSDR , EF MMSRR , EF MMSL , EF UST ) either already exist or are added to the file structure of said at least one 
storage medium. 

Method according to claim 8 or 9 characterized in that a status byte is included in records of a file (EF MMSN ) 
which comprises at least one MMS notification wherein the status byte comprises information regarding the status 
of the MM S notification message, the delivery report and/or the MM retrieval. 

Method according to claim 8 or 9 characterized in that a status byte is included in records of a file (EF MM ) which 
comprises at least one Multimedia Message (MM) wherein the status byte comprises information regarding the 
receipt of a MM, the reading status of a MM, the origin of a MM, the submission of a MM, the delivery report and/ 
or the read-reply report. 

Method according to claim 10 or 11 characterized in that the status byte is used as a pattern in the SEARCH 
RECORD command being a function on the interface between the terminal of said apparatus or said device and 
said at least one storage medium. 

Method according to any one of claims 10 to 12 characterized in that the status byte is updated when said at 
least one storage medium is connected to an User Agent (UA) and said User Agent receives an MMS notification, 
receives an MM, receives an MMS delivery report and/or receives an MMS read-reply report or originates an MM, 
allows/disallows the creation of an MMS delivery report and/or originates an MMS read-reply report to be stored 
on said at least one storage medium. 

Method accordingto anyone of the preceding claims characterized in that one or more of the following information 
are included and/or accessed in the records of a file (EF MMSS ) which relates to MMS-related status information: 

a unique reference assigned to the MM (Message-ID); 

available memory for MMS-notifications (MMS notification memory capacity); 
available memory for MMs (MM memory capacity); 
available memory for delivery reports (MMS delivery report memory); 
available memory for read reply reports (MMS read reply report memory capacity). 

Method accordingto any one of the preceding claims characterized in that one or more of the following information 
are included and/or accessed in the records of a file (EF MMSP ) which relates to MMS-related values for Multimedia 
Messaging Parameters: 

alpha Tag associated to the MMS-parameter (Alpha-Identifier) ; 
40 - Parameter Indicators which indicate the presence of MMS related parameters; 

MMS Implementation which indicate the used protocol; 
Length of the originator address; 
Length of the recipient address; 
Length of the MMS Relay/Server address; 
45 - Length of the expiry time; 

Length of earliest time of delivery; 
Length of the message class; 
Length of Sender visibility request; 
Length of Delivery report request; 
50 - Length of Read reply report request; 

Length of Priority of message; 
Originator address; 
Recipient address; 
MMS Relay/Server address; 
55 - Expiry time of message; 

Earliest time of delivery of message; 
Message class; 
Sender visibility request; 
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Delivery report request; 
Read reply report request; 
Priority of message. 

5 16. Method according to any one of the preceding claims characterized in that one or more of the following information 
are included and/or accessed in the records of a file (EF MMSDR ) which relates to multimedia message delivery 
reports: 

MMS delivery report identifier identifying the corresponding MM record in the elementary file EF MM ; 
10 - MMS delivery report containing the MMS-DELIVERY-RECORD. 

1 7. Method accordi ng to any one of the preceding claims characterized in that one or more of the following information 
are included in the records of a file (EF MMSRR ) which relates to multimedia-message read reply reports: 

15 - MMS read reply record identifier identifying the corresponding MM record in the elementary file EF MM ; 

- MMS read reply containing the M MS-READ-REPLY-RECORD. 

1 8. Method according to any one of the preceding claims characterized in that one or more of the following information 
are included and/or accessed in the records of a file (EF MMSL ) which comprises values for MMS record size limi- 

20 tations, preferably defined by the authority owning said at least one storage medium: 

Length of a record in EF MMSN ; 
Length of a record in EF MM ; 
Length of a record in EF MMSS ; 
25 - Length of a record in EF MMSP ; 

Length of a record in EF MMSDR ; 
Length of a record in EF MMSRR . 

19. Method according to any one of the preceding claims characterized in that one or more MMS-services are added 
30 to the records of the elementary file EF UST (USIM Service Table), e.g. Multimedia Message Notification, Multimedia 

Message Service Storage, Multimedia Message Service Delivery Report, Multimedia Message Read Reply Report, 
Multimedia Message Parameters, Multimedia Message Service Status, Multimedia Message Service Limitations. 

20. Method according to any one of the preceding claims characterized in that one or more of the following information 
35 are stored and/or accessed in one generic elementary file (EF MMS ) : 

Status of the Multimedia Message (received, originated, submitted); 
Message type; 
Message content. 

40 

21 . Method according to any one of the preceding claims characterized in that MMS notification messages are stored 
and/or accessed in the elementary file EF SMS containing information which comprise mobile terminated or mobile 
originated short messages. 

45 22. Method according to claim 21 characterized in that a status byte is included in the records of said elementary 
file (EF SMS ) said status byte comprising information regarding the MMS notification. 

23. Method according to claim 22 characterized in that the status byte is used as a pattern in the SEARCH RECORD 
command being a function on the interface between the terminal of said apparatus or said device and said at least 

50 one storage medium. 

24. Storage medium for storing and/or allowing access to MMS-related information, especially information stored ac- 
cording to any one of the preceding claims, for use in an apparatus, said apparatus comprising means for process- 
ing said MMS-information, characterized in that said storage medium is designed such that it can be connected 

55 to and disconnected from said apparatus. 

25. Storage medium according to claim 24 that it is a smart card. 
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26. Storage medium according to claim 25 that it is a SIM (Subscriber Identity Module). 

27. Storage medium according to claim 25 that it is a USIM (UMTS Subscriber Identity Module) on a UICC (Universal 
Integrated Circuit Card). 

5 

28. Storage medium according to claim 25 that it is a WIM (WAP Wireless Identity Module). 

29. Storage medium according to claim 25 that it is a MMC (Multimedia Card). 

10 30. Storage medium according to any one of claims 24 to 29 characterized in that one or more of the following MMS- 
related information are storable and/or accessible on said storage medium: 

MMS notifications; 

Entire Multimedia Messages (MM) or parts thereof; 
MMS delivery reports; 
MMS read-reply reports; 
MMS parameters; 
MMS status information; 

MMS limitations information defined by the authority that owns the smart card; 
Indication of the MMS-services being available. 



15 



20 



25 



31. Storage medium according to any one of claims 24 to 30 characterized in that said MMS-related information is 
storable and/or accessible in several elementary files (EFy MSN , EF MM , EF MMSS , EF MMSP , EF MMSDR| EF MMSRRf 
ef mmsl» *= f ust) and/or dedicated files and/or the master file. 

32. Storage medium according to any one of claims 24 to 30 characterized in that said MMS-related information is 
storable and/or accessible in one universal (generic) elementary file (EF MMS ). 

33. Storage medium according to any one of claims 24 to 30 characterized in that said MMS-related information is 
30 storable and/or accessible in the elementary file EF SMS . 

34. Apparatus comprising means for storing and/or accessing MMS-related information according to any one of the 
steps of the claims 1 to 23 on a storage medium according to any one of the claims 24 to 33. 

35 35. Apparatus according to claim 34 characterized in that it is a mobile communication apparatus, especially a mobile 
phone. 

36. Apparatus according to claim 34 characterized in that it is an external device connectable to a mobile commu- 
nication apparatus, especially a notebook, a laptop or an electronic organizer. 

40 

37. A software program comprising program code means wherein said software program may be run on an apparatus, 
especially an apparatus according to any one of claims 34 to 36, such that said software program together with 
said apparatus performs all the steps of any one of the claims 1 to 23. 

45 38. A software program comprising program code means which is loadable on an apparatus, especially an apparatus 
according to any one of claim 34 to 36, such that said programmed apparatus is adapted to perform all the steps 
of any one of the claims 1 to 23. 

50 
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FIG 4 (State of the Art) 





MM1 SQ 



MM1 SR 



MM1_DRQ 
MM1 RRQ 0 



MM4 FQ 



MM4 FR 




MM4 DRQ 



MM4 RRQ 




MM1 NQ 



MM1NR 
MM1 RQ 



MM1 RR 



MM1 AQ 



MM1 RRQ R 



mandatory message 
optional message 



39 




EP 1 255 416 A1 



CD ^ ^ 

S CO "co* 
GO CO CO CD 

CD ' 

az 

"cr co 

CD CO CD 

rr ro -3- 



-2 8^ 



CD 

O CO >rr* 

_ £ g £ > 

Jrr OO CD v— ^*"0 

^ 2f ^ - 



o o co * 

CO CD 

03 s i8c 



cd s oa 



LO 

CD 



a. c= 
<C -o 



193.9 
2.35. 

DO 


andreas. 
Schmidt@sal. 
siemens.de 


sabine. van. 
niekerk@sal. 
siemens.de 




00 co 




II §, 




CO 03 






CO CO 
CO CD 

II =^ 


WAP 








CO 




co 








CD 




CD 




CD 




CO 




CD 




CO 




CO 




CD 




CO 




CO 





















number 








L I 1 




CO 


r — > 


LO 


#*— > 

V J 








* > 


CNJ 


f N 

V J 




V J 


CO 


CO 


CT> 


* \ 

v •> 


CO 


V > 


r-- 


V 


CO 


CO 


LO 


CO 




CO 


co 




CNJ 









CO 
CD 



40 



EP 1 255 416 A1 



ADFjSIM 



FIG 7 



Uh PHONEBOOK 
' 5F3A 1 


dfgsm 

1 5F3B ' ! 


ur MExE 
1 ' 5F3C ' 




1 
1 

see 
36 TS 
31.102 


1 
1 

see 
36 TS 
31.102 

i 


see 
3GTS 
31.102 


- i i i 


ef L i 

1 6F05 1 


efarr 

1 6F06 1 


I 

EF|MSI 
' 6F07 ' 


EF«eys 
' 6F08 ' 


EFKeysPS 
'6F09' 


efdck 

" 6F2C ' 


1 

EF HPLMN 
1 6F31 ' 


EFCNL 
1 6F32 1 


I 

EFACMmax 
' 6F37 ' 


EFUST 
' 6F38 ' 


I 

efacm 

i '6F39' 


1 

effdn 

' 6F3B ' 


I 

EFSMS 
1 6F3C ' 


I 

EFGID1 
•6F3E" 


i 

EFGID2 
' 6F3F ' 


1 

efmsisdn 

'6F40' 


1 

EFpuCT 
•6F41 ' 


EFSMSP 
' 6F42 ' 


1 1 1 1 1 1 


F-FSMSS 
1 6F43 ' 


EFCBMI 
' 6F45 ' 


EFSPN ! 
• 6F46 1 


EFSMSR 
1 6F47 1 


EFCBMID 
! ' 6F48 ' 


EFSDN 
. ' 6F49 ' 


l 

EF EXT2 
'6F4B" 


I 

EF EXT3 
'6F4C 


l 

EF BDN 
' 6F4D ' 


l 

EF EXT5 
' 6F4E • 


I 

EFCBMIR 
' 6F50 ' 


1 

EFEXT4 
' 6F55 ' 


efest 

' 6F56 ' 


; EFacl 
' 6F57 ' 


i 

EFCMI ! 
' 6F58 ' I 


l 

EFSTART-HFN 
'6F5B' 


i 

efthreshold 

'6F5C 


i 

EFpLMNwAcT 
' 6F60 ' 


1 1 1 1 " 1 1 


F-FoPLMNwAcT 
' 6F61 ' 


EFHPLMNwAcT 
1 6F62 ' 


EFRPLMNAcT 
' 6F65 1 


eflocips 

' 6F73 ' 


efacc 

' 6F78 ' 


f EF F pLMN 
•6F7B' 


1 1 1 1 1 1 


l 

F-FLOCI 
' 6F7E ' 1 


EF,ci 
' 6F80 ' 


i 

EFOCI 1 
' 6F81 ' 


EFlCT 
' 6F82 ' 


EFOCT 
• 6F83 ' 


efad 

' 6FAD ' 


i 1 " ™ i 1 




EFeMLPP 
' 6FB5 1 


EFAAeM 
! ' 6FB6 ' 


efecc 

' 6FB7 ' 


EFHiddenkey 
' 6FC3 ' 




— 1 1 1 1 




efmmsn 

' 6FD0 ' 


| EFmm 
' 6FD1 1 


efmmsp 

' 6FD2 1 


efmmss 

' 6FD3 ' 


efmmsdr 

' 6FD4 ' ! 


efmmsrr 

'6FD5' 



efmmsl 

'6FD6' 



41 



EP1 255 416 A1 



European Patent 
Office 



PARTIAL EUROPEAN SEARCH REPORT 



Application Number 



which under Rule 45 ol the European Patent Convention£ p Q 1 11 0877 
shall be considered, for the purposes of subsequent 
proceedings, as the European search report 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate. 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lnta.7) 



EP 1 059 822 A (NOKIA MOBILE PHONES LTD) 
13 December 2000 (2000-12-13) 

* page 1, line 6 - page 6, line 23 * 

* figures 1,3,4 * 



ETSI: "Digital cellular 
telecommunications system (Phase 
2+) Specification of the Subscriber 
Identity Module - Mobile Equipment (SIM - 
ME) interface (GSM 11.11 version 6.2.0 
Release 1997)" 
TS 100977 V6.2.0, XX, XX, 
May 1999 (1999-05), XP002158150 

* page 13, last paragraph - page 15, 
paragraph 9 * 

* page 21, paragraph 12 - page 103, last 
paragraph * 



1-4, 
24-29 



5-23, 
30-36 

5-23, 
30-36 



H04Q7/32 

H04M3/533 

H04L12/58 



-/- 



TECHNICAL FIELDS 
SEARCHED (lnt.CL7) 



H040 

H04M 
H04L 



INCOMPLETE SEARCH 



The Search Division considers lhat the present application, or one or more of rts claims, does/do 
not comply with the EPC to such an extent that a meaningful search Intc the sta:o of the art cannot 
be carried out, or can only be carried out partially, lor these claims. 

Claims searched completely : 

1-36 

Claims searched Incompletely : 
Claims not searched : 

37-38 

Reason tor the limitation ol the search: 

Article 52 (2)(c) EPC - Program for computers 



Place ol search 

MUNICH 



Dale cf completion of the seaich 

16 November 2001 



Examiner 

Nash, M 



CATEGORY OF CITED DOCUMENTS 

X : particularly rolevanl If taken alone 

Y : particularly relevant if combined »nih anoiher 

document of the same category 
A : technological background 
O : non-written disclosure 
P : Intermediate document 



T : theory or principle underlying liie Invention 
E : earner oatent document, b Jt published on, or 

after the filing date 
D : docun>en1 cited In Ihe application 
l_ : document cited for other reasons 

& : member ot the same patent 'am'iiy, corresponding 
document 



42 



EP 1 255 416 A1 




in Patent PARTIAL EUROPEAN SEARCH REPORT Application Number 

EP 01 11 0877 



DOCUMENTS CONSIDERED TO BE RELEVANT 


CLASSIFICATION OF THE 
APPLICATION (lnt.CL7) 


Category 


Citation of document with indication, where appropriate, 
of relevant passages 


Relevant 
to claim 




X 

A 


MAZZI0TT0 G: "THE SUBSCRIBER IDENTITY 
MODULE FOR THE EUROPEAN DIGITAL CELLULAR 
SYSTEM GSM AND OTHER MOBILE COMMUNICATION 

SYSTEMS" 

PROCEEDINGS OF THE INTERNATIONAL SWITCHING 
SYMPOSIUM. YOKOHAMA, OCT. 25 - 30, 1992, 
TOKYO, IEICE, JP, 
vol. 1 SYMP. 14, 

25 October 1992 (1992-10-25), pages 
113-116, XP000337627 
* the whole document * 


1-3,24, 
25,34-36 

4-23, 
26-33 


TECHNICAL FIELDS 
SEARCHED (lntCI.7) 







43 



EP 1 255 416 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 01 11 0877 



This annex lists the patent family members relating to the patent documents cited in the above-mentioned European search report. 
The members are as contained in the European Patent Office EDP file on 

The European Patent Office Is in no way liable for these particulars which are merely given for the purpose of information. 

16-11-2001 



Patent document 
cited in search report 



Publication 



Patent family 
member(s) 



Publication 
date 



EP 1059822 



13-12-2000 



BR 0002069 A 

CN 1276694 A 

EP 1059822 A2 

OP 2001016634 A 



02-01-2001 
13-12-2000 
13-12-2000 
19-01-2001 



i For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



44 



